REMARKS 

The present application has been reviewed in light of the Office Action dated 
November 16, 2009. Claims 1-13, 15, and 17 are presented for examination, of which Claims 1, 
2, 6, 9, 12, and 13 are in independent form. Claims 1-6, 9-13, 15, and 17 have been amended to 
define aspects of Applicant's invention more clearly. Favorable consideration is requested. 

The Office Action states that Claims 1-13, 15, and 17 are rejected under 35 U.S.C. 
§ 102(b) as being anticipated by U.S. Patent No. 6,122,639 (Babu et al). For at least the 
following reasons, Applicant submits that independent Claims 1, 2, 6, 9, 12, and 13, together 
with the claims dependent therefrom, are patentably distinct from the cited prior art. 

The aspect of the present invention set forth in Claim 1 is directed to a network 
device managing apparatus that receives search requests transmitted from data processing 
apparatuses, performs searches for network devices in response to receiving the search requests, 
and transmits device lists indicating the network devices found by performing the searches to the 
data processing apparatuses. The network device managing apparatus includes a first receiving 
unit, a first searching unit, a storage unit adapted, a second receiving unit, an obtaining unit, a 
second searching unit, a comparing unit, and a forming unit. 

The first receiving unit receives, from a data processing apparatus, a first search 
request for a first search for network devices and identification information identifying the data 
processing apparatus that transmitted the first search request. In response to the first search 
request received by the first receiving unit, the first searching unit performs the first search for 
network devices. The storage unit stores a first device list indicating the network devices found 
by performing the first search. 
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Notably, the first device list is stored in association with the identification 
information identifying the data processing apparatus that transmitted the first search request. 
The second receiving unit receives, from a data processing apparatus, a second search request for 
a second search for network devices and identification information identifying the data 
processing apparatus that transmitted the second search request. In response to the second search 
request being received by the second receiving unit, the second searching unit performs the 
second search for network devices. If the identification information received by the second 
receiving unit is equal to the identification information associated with the first device list by the 
storage unit, the obtaining unit uses the identification information received by the second 
receiving unit as a key to obtain, from among device lists stored in the storage unit, the first 
device list associated with the identification information identifying the data processing 
apparatus that transmitted the first search request. The first device list indicating a first search 
result provided by the first searching unit. The comparing unit compares a second search result 
provided by the second searching unit with the first search result indicated by the first device. 
The forming unit specifies one or more network devices found by perf orming the second search 
by the second searching unit, but not present in the first search result indicated by the first device 
list, and forms a second device list in which the one or more network devices are emphasized 
among network devices found by performing the second search. The transmitting unit transmits 
the second device list formed by the forming unit to the data processing apparatus that 
transmitted the second search request. 

By virtue of the operation of the storage, obtaining, comparing, and forming units, 
a server can receive a first search request from a first client, perform a first search based on the 
first search request, and store a first device list associated with information identifying the first 
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client in the storage unit, wherein the first device list includes results of performing the first 
search. In response to a second search request from the first client, the server can perform a 
second search and create a second device list that is updated based on the first device list 
associated with the information identifying the first client, wherein the second device list 
includes, in a bold face font, for example, devices found by performing the second search that are 
not included the first device list associated with the information identifying first client. 1 

Babu et al. is understood to relate to collecting, detecting changes in, reporting, 
and managing network device information (see col. 1, lines 5-8). Babu et al. discusses that a 
Network Management Server 102 can open and establish a Hypertext Transfer Protocol (HTTP) 
connection 1 12 with a browser running on a client 104 (see col. 6, lines 2-4, and 41-45). A 
network device 118 can respond to a Simple Network Management Protocol (SNMP) Query by 
providing "Basic Device Data" about the device 118, which can include a device name, a domain 
name in which the device is located, and a "Device Type" code that identifies a specific type of 
device, e.g., a model number (see col. 7, line 67, to col. 8, line 6). The Device Type code 
received from the network device 118 can be mapped to a stored list of device types, in order to 
determine whether the Device Type of the responding network device is known and can be 
handled (see col. 8, lines 7-10). 

Babu et al. also discusses that operation of a Collection Engine 20 can be initiated 
by supplying a device name 14, and other information with which the Collection Engine 20 can 
locate a device, such as SNMP community strings (see col. 7, lines 19-23). For example, an 
application program can request that the Collection Engine 20 collect data from a particular 



- Any examples presented herein are intended for illustrative purposes and are not to be 
construed to limit the scope of the claims. 
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network device 1 18 by supplying a device name 14 that identifies the network device 118 (see 
col. 7, lines 23-28). In response, the Collection Engine 20 can send an SNMP message over a 
network to the network device 118 (see col. 7, lines 29-31). The network device 118 can respond 
by providing a device type identifier (see col. 7, lines 42-44). The Collection Engine 20 can 
gather information from many different network devices, each of which has different physical, 
hardware, software, and firmware characteristics (see col. 13, lines 14-17). Information collected 
by the Collection Engine 20 from a device can be defined by a set of database system tables 
called Management Information Base (MIB) Sets (see col. 13, lines 17-20). Each MIB Set can 
define a full set of device data to be collected and stored in a Destination Device Data Table (see 
col. 13, lines 20-22). A collection of MIB Sets needed to fully describe a particular device can be 
determined by a Device Class to which a device belongs, which can be determined by acquiring a 
device type identifier or sysObjectID from the device, mapping the sysObjectID to the Device 
Type, and then mapping the Device Type to the Device Class (see col. 13, lines 22-28). 

The Collection Engine 20 can stores "current" values received from the device 
1 18 in a Main Memory 506, which allows values received in the past and stored in a Database 40 
to be stored into memory and related (see col. 12, lines 45-55). Alternatively, the Database 40 
can maintain one set of tables that store the "current" values received from the device 118 and a 
separate set of tables of values that have been received in the past (see col. 12, lines 55-58). 

In addition, Babu et al. discusses that a device type identifier 16 can be used as a 
key to a Device Type Table 44, which contains rows for unique SysObjectID values and columns 
for class identifiers for the devices, names of the devices, manufacturers of the devices, and 
descriptions of the devices (see col. 8, lines 10-16, and col. 12, lines 34-36). Information from 
the Device Type Table 44 can be used to determine a device class, which can be obtained from a 
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Device Class Table 46 (see col. 12, lines 34-36). The Collection Engine 20 can use a Device 
Class to MIB Set Table in the Database 40, to look up identifiers for MIB Sets 50 that match the 
device type identifier 1 16 (see col. 12, lines 36-39). Upon receiving the identifiers for matching 
MIB Sets 50, the Collection Engine 20 can request that the Database 40 retrieve copies of the 
MIB Sets 50, which the Database 40 returns to the Collection Engine 20 (see col. 12, lines 39- 
44). 

Babu et al. further discusses that a change detection mechanism can generate a 
report containing change information, and that database updates can be found during a database 
key comparison phase of the change detection mechanism (see col. 15, lines 7-10, and lines 28- 
30). A comparison can be performed to detect changes in a device's configuration, and the 
detected changes can be stored in a change table of a database (see col. 15, lines 41-45). Column 
names displayed by the change detection mechanism can be consistent with column names or 
labels displayed by an application program that defined them, which allows the change detection 
mechanism to work with any database table, independent of the column layout of such (see col. 
14, lines 19-26). 

As best understood by Applicant, the database tables of Babu et al. contain 
information about the network devices 118 and information collected from the network devices 
118; however, these tables are not understood to be associated with information identifying a 
particular client 104 that requested information about the network devices 118. Accordingly, 
when the client 104 requests that the Collection Engine 20 provide information collected from a 
particular network device 118, the Collection Engine 20 is not understood to retrieve from the 
Database 40 tables associated with information identifying the client 104 that requested the 
information. Instead, the tables stored by the Database 40 that include network information 
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collected from a particular network device 118 are understood to be associated with information 
identifying the particular network device 118. 

In summary, nothing has been found in Babu et al. that is believed to teach or 
suggest a network device managing apparatus that includes a "storage unit adapted to store a first 
device list indicating the network devices found by performing the first search, the first device 
list being stored in association with the identification information identifying the data processing 
apparatus that transmitted the first search request," an "obtaining unit adapted to use the 
identification information received by the second receiving unit as a key to obtain, from among 
device lists stored in the storage unit, the first device list associated with the identification 
information identifying the data processing apparatus that transmitted the first search request, if 
the identification information received by the second receiving unit is equal to the identification 
information associated with the first device list by the storage unit, the first device list indicating 
a first search result provided by the first searching unit," a "comparing unit adapted to compare a 
second search result provided by the second searching unit with the first search result indicated 
by the first device list obtained by the obtaining unit," and a "forming unit adapted to specify one 
or more network devices found by performing the second search by the second searching unit but 
not present in the first search result indicated by the first device list obtained by the obtaining 
unit, and to form a second device list in which the one or more network devices are emphasized 
among network devices found by performing the second search," as recited in Claim 1. 
Accordingly, Applicant submits that Claim 1 is not anticipated by Babu et al. , and respectfully 
requests withdrawal of the rejection under 35 U.S.C. § 102(b). 

Independent Claims 2, 6, 9, 12, and 13 include features sufficiently similar to 
those of Claim 1 that these claims are believed to be patentable over the cited art for at least the 
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reasons discussed above. The other claims in the present application depend from one or another 
of independent Claims 1, 2, 6, and 9, and are submitted to be patentable for at least the same 
reasons. Because each dependent claim also is deemed to define an additional aspect of the 
invention, however, individual consideration of the patentability of each claim on its own merits 
is respectfully requested. 

In view of the foregoing amendments and remarks, Applicant respectfully requests 
favorable consideration and an early passage to issue of the present application. 

Applicant's undersigned attorney may be reached in our New York Office by 
telephone at (2 1 2) 2 1 8-2 1 00. All correspondence should be directed to our address listed below. 

Respectfully submitted, 

/Lock See Yu-Jahnes/ 
Lock See Yu-Jahnes 
Attorney for Applicant 
Registration No. 38,667 

FLTZPATRICK, CELLA, HARPER & SCINTO 
1290 Avenue of the Americas 
New York, New York 10104-3800 
Facsimile: (212) 218-2200 
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